容器云统一认证中心的三个W：Why，What，How
本文探讨了：
Why-- 为什么要考虑统一认证中心
What-- 统一认证中心应实现什么功能
How-- 容器云统一认证中心的实现设计
原题：容器云统一认证中心设计
作者：汪照辉 王作敬 中国银河证券股份有限公司 信息技术部IT研发中心
我们在考虑容器云架构的时候，安全是我们考虑的一个重要方面。前期我们提出了容器云多租户权限中心的设计，不少同行给予了肯定。（见《容器云厂商普遍难以满足的需求——容器云多租户及权限中心设计》）但仅有权限中心，还不足以支撑容器云系统的安全能力。今天我们基于权限中心的设计，更进一步讨论下容器云统一认证中心的设计。
统一认证在容器云平台涉及两个层次的认证，一是容器云平台本身各组件的统一的权限管理和授权认证，二是容器云平台之上应用服务之间访问跳转的统一认证授权管理，这部分区别于我们容器云平台运维管理，是客户的访问控制逻辑。这里我们重点讨论容器云平台层统一认证体系，实际的业务应用服务的统一认证实现我们将在后期深入讨论。
一、为什么考虑统一认证中心
当前容器云产品基本上都是基于开源组件的构建和实现，一个容器云就可能涉及大大小小几十个甚至上百个组件。而且大部分组件都有自己的一套访问控制机制，比如说容器的编排调度、镜像仓库、日志组件、监控组件等等。对于我们终端用户来说，我们不希望每个组件都维护一套用户权限体系，我们希望容器云平台能够基于解耦合、插件化的架构方式来支持一套用户权限管理架构，所有组件的用户权限管理、访问控制逻辑打通，实现统一的认证、授权、准入等访问控制机制。
当然也有厂商说他们的容器云平台把所有组件都紧耦合集成到了一起，不需要考虑统一认证了。也没问题，不同的理解不同的实现方式。我们为什么不考虑容器云平台的紧耦合集成呢？其实在我们前面的文章《云计算杂谈》中也提到过，生产环境的技术采用不是玩过家家，不是为了简单的PoC测试，我们需要充分考虑可能会遇到的潜在的需求和问题。工欲善其事，必先利其器！容器云平台要上生产，其自身的架构和可扩展性、可移植性、可替换性、高可用性等要求其必须具备松耦合、插件化的能力。其实目前大家热衷的微服务思想就是自成一体的自治性和标准的集成接口。
所以，我们要求我们采用的容器云平台具备组件自身自治能力和标准化的松耦合集成能力。
二、统一认证中心实现什么功能
统一认证的设计讨论也很多，成熟的产品也很多，这里我们也不深入讨论了。我们就简单看下从我们的角度——容器云平台运维管理人员角度希望实现哪些能力。我们觉得作为基础设施的云计算容器云平台，统一认证中心需要考虑支持下列能力：
用户管理：对用户的增、删、改、查、授权、密码管理等，支持第三方用户管理系统，比如AD、Ldap等。
权限管理：对不同资源的操作定义。比如增、删、改、查等。
角色管理：一组权限集合定义为一个角色。
组织架构管理：支持不同的组织架构层级定义需求。用户属于组织，用户可以被授权（分配角色），组织也可以被授权（分配角色），所在组织的用户自动集成该组织的权限。
资源管理：需要进行权限控制的所有基础设施资源、业务应用、服务等。
单点登录：一点登录、全网可用。用户只需要登录一次就可以访问所有相互信任的应用系统。
用户认证、授权、准入
会话管理：用户登录之后会话的创建、维护、管理、统计等。
支持多种认证方式：比如简单的用户名/密码认证、用户名密码+验证码认证、数字证书认证、动态口令认证等
三、用户管理、权限管理、角色管理、组织架构管理和资源管理
用户管理、权限管理、角色管理、组织架构和资源管理我们在《容器云多租户权限中心设计》中已经讨论过了，这里不再赘述。网上也有很多资源可供参考。
多啰嗦一句的是，资源不只是容器云基础设施资源，也包括容器云之上部署的业务应用和服务资源。
四、单点登录
我们先看下“单点登录”。前面我们也提到，基于开源的容器云平台，用到的开源组件非常多，大部分开源组件都有自己的一套权限管理认证体系，而且很多采用的是不一样的权限管理认证方式，在容器云厂商提供给我们客户使用容器云产品的时候，一方面我们会考虑安全性是否足够强壮的问题，另一方面也不希望访问一个组件，就登录认证一次，单独维护一套用户权限访问体系。这样太繁琐，不适用于真正的企业生产。另外我们也提到过，企业生产环境不是简单的PoC测试验证一下，我们要求容器云平台各个组件是解耦合、插件化、服务化的架构方式，可以方便的插拔来选择需要的组件，这样可以方便的跟企业已有的系统集成结合，一个组件类似于一个自治的服务。
我们希望把权限中心分离出来，统一认证中心分离出来，甚至单点登录分离出来作为一个服务，在一个企业的内部实现服务的共享，这也是我们做SOA，服务化或者微服务的一个重要的价值。一个企业业务系统最终发展的架构也将可能会是一个且是仅有的一个分布式化、服务化的巨大的“单体”应用。
单点登录是一种会话/用户身份验证过程，允许用户一次性提供其凭据，以便访问多个应用程序。单点登录的用户进行身份验证，确认他或她已被授权访问，可以访问所有的应用程序。在特定的会话期间当用户切换应用程序时，不需要再次发送认证请求。单点登录的技术也已经非常成熟，基本上大部分的企业也都已经部署了“单点登录”系统。这里我们只是提供一种思路，深入的知识请参考相应的技术资料或产品资料。
五、用户认证、授权、准入
Kubernetes提供了认证、授权、准入的机制，我们觉得这种机制非常好，所以希望在容器云平台上甚至可以是延伸到整个企业业务应用的方案，而不只是一个Kubernetes的方案。
认证实现验证请求访问的用户是谁，是否是合法用户。下面我们也会讨论不同的认证方式支持需求。
授权就是授予不同用户不同的权限。我们期望的授权方式是基于角色的授权，权限中心可以实现这部分工作。
准入控制是对经过授权认证的用户进行访问控制，通过准入控制列表，来判断用户是否可以访问请求的资源。准入控制也是实现安全的一个重要方面，如果遇到合法用户的大量访问（合法攻击），可以在准入控制层拒绝频繁访问。准入控制和我们通常所说的黑名单、白名单的控制逻辑类似。
六、会话管理
会话管理一般由统一认证模块或统一认证服务来实现，是实现管理员查看、浏览与检索用户登录情况——谁在哪里登录了等，管理员也可以在线强制用户退出当前的应用登录。用户登录之后会创建会话直到用户登出。一般会提供Admin console或Admin UI来支持。可以参阅相关实现统一认证功能的产品的文档获取详细资料。
七、支持多种认证方式
通常情况下，我们一般只是使用简单的用户名、密码来实现基本的认证，每个用户再赋予相应的权限，就实现了基本的访问控制。
但随着云计算的发展，安全性是一个互联网应用面对的越来越艰巨的任务。即便是企业内部搭建的私有云，也面临着整个生态的互连互通，需要和其他企业的系统进行通信和信息交换。企业内部可能相对简单，简单的用户名/密码认证，可以满足企业内部的基本安全需求。但有时可以需要证书、或者动态口令等认证方式。这就要求我们的统一认证中心提供不同的认证支持能力。开源组件KeyCloak，CAS等都提供了不同的认证方式支持。
八、容器云统一认证中心的实现设计
统一认证实现有多种方式，目前也有不少成熟的产品。开源的组件比如CAS、KeyCloak等也提供了强大的功能。
其实就像我们提出的自主研发要求，自主研发也不是什么事情都自己干，关键是想清楚需要做什么、怎么做、什么时候用什么工具什么方式做。自己有掌控整个项目的能力。容器云统一认证中心的实现也是一样的道理。可以采用成熟的开源组件，集成到容器云平台，同时结合容器云权限中心的设计，实现容器云平台的用户统一身份认证。
这里举例来说，容器云平台和镜像仓库各自有自己独立的认证体系，我们希望实现容器云平台和镜像仓库的统一认证。比如可以采用KeyCloak实现统一认证和单点登录功能，结合我们设计的权限中心服务，共同来实现容器云的统一认证服务。
用户请求登录容器云平台。
转发用户登录请求到认证中心。
认证中心验证用户，没有登录则转发请求到权限中心，验证用户身份，合法则创建会话token，不合法则拒绝登录。
返回验证请求的资源是否有访问权限
有权限且不受准入限制则准许访问，否则拒绝访问。
通知用户登录是否成功。
用户访问镜像仓库组件，镜像仓库需要认证用户
访问请求被转发到认证中心，验证用户是否合法，是否已经登录
如果用户已经登录，则返回用户的token
返回请求的资源（同样可能需要访问权限中心验证对访问的资源是否有授权）。
这里只是一个简单的思路。抛砖引玉希望能给大家一些启发。
九、业务应用服务的统一认证
业务应用服务的统一认证是另外一个层次的问题，这里我们主要讨论的是容器云平台各组件各模块之间的统一认证服务。当然搭建了统一认证中心，不管开发运维角度，或者从客户访问认证管理角度，都可以去实现。
十、写在最后
受互联网技术的影响，容器应运而生，微服务生逢其时，云计算作为基础设施平台，很可能将会支撑起一家公司的所有系统。我们相信，传统公司业务系统的发展逐步会走向分布式化、服务化、标准化、自治的满足整个公司业务需求的一个统一的“单体”应用。一个公司只需要一套日志系统，一套监控系统，一套认证系统，一套配置系统，一套……从而实现一个公司的数据的集中和统一，服务的共享和标准化，业务的快速响应和变化。
参考文献
1．Keycloak http://www.keycloak.org/documentation.html
2．CAS https://www.apereo.org/projects/cas
更多相关文章，请点击阅读原文
长按二维码关注公众号